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Abstract 

A secure timeline is a tamper-evident historic record 
of the states through which a system goes throughout 
its operational history. Secure timelines can help us 
reason about the temporal ordering of system states 
in a provable manner. We extend secure timelines to 
encompass multiple, mutually distrustful services, us- 
ing timeline entanglement. Timeline entanglement as- 
sociates disparate timelines maintained at independent 
systems, by linking undeniably the past of one timeline 
to the future of another. Timeline entanglement is a 
sound method to map a time step in the history of one 
service onto the timeline of another, and helps clients 
of entangled services to get persistent temporal proofs 
for services rendered that survive the demise or non- 
cooperation of the originating service. In this paper we 
present the design and implementation of Timeweave, 
our service development framework for timeline entan- 
glement based on two novel disk-based authenticated 
data structures. We evaluate Timeweave's performance 
characteristics and show that it can be efficiently de- 
ployed in a loosely-coupled distributed system of a few 
hundred services with overhead of roughly 2-8% of the 
processing resources of a PC-grade system. 



1 Introduction 

A large portion of the functionality offered by cur- 
rent commercial "secure" or "trusted" on-line ser- 
vices focuses on the here and now: certification au- 
thorities certify that a public signature verification 
key belongs to a named signer, secure file systems 
vouch that the file with which they answer a lookup 
query is the one originally stored, and trusted third 
parties guarantee that they do whatever they are 
trusted to do when they do it. 

The concept of history has received consider- 
ably less attention in systems and security research. 
What did the certification authority certify a year 



ago, and which file did the secure file system return 
to a given query last week? 

Interest in such questions is fueled by more than 
just curiosity. Consider a scenario where Alice, 
a certified accountant, consults confidential docu- 
ments supplied by a business manager at client com- 
pany Nome, Inc. so as to prepare a financial re- 
port on behalf of the company for the Securities 
and Exchange Commission (SEC). If, in the future, 
the SEC questions Alice's integrity, accusing her of 
having used old, obsolete financial information to 
prepare her report, Alice might have to prove to 
the SEC exactly what information she had received 
from Nome, Inc. before preparing her report. To 
do that, she would have to rely on authentic his- 
toric data about documents and communication ex- 
changes between herself and Nome, on the authen- 
tic, relative and absolute timing of those exchanges, 
perhaps even on the contents of the business agree- 
ment between herself and the company at the time. 
Especially if the company maliciously chooses to 
tamper with or even erase its local records to repudi- 
ate potential transgressions, Alice would be able to 
redeem herself only by providing undeniable proof 
that at the time in question, Nome, Inc. did in fact 
present her with the documents it now denies. 

Besides this basic problem, many other periph- 
eral problems lurk: what if Nome, Inc. no longer 
exists when Alice has to account for her actions? 
What if Alice and the SEC belong to different trust 
domains, i.e., have different certification authorities 
or different secure time stamping services? 

In this work we formulate the concept of secure 
timelines based on traditional time stamping ]ff|, p[ 
and authenticated dictionaries || [to] (Section [|). 
Secure timelines allow the maintenance of a persis- 
tent, authenticated record of the sequence of states 
that an accountable service takes during its lifetime. 

Furthermore, we describe a technique called time- 



2 



line entanglement for building a single, common 
tamper-evident history for multiple mutually dis- 
trustful entities (Section [|) . First, timeline entan- 
glement enables the temporal correlation of inde- 
pendent histories, thereby yielding a single timeline 
that encompasses events on independent systems. 
This correlation can be verified independently in the 
trust domain of each participant, albeit with some 
loss of temporal resolution. Second, it allows clients 
to preserve the provability of temporal relationships 
among system states, even when the systems whose 
states are in question no longer participate in the 
collective, or are no longer in existence. 

We then present Timeweave, our prototype 
framework for the development of loosely-coupled 
distributed systems of accountable services that 
uses timeline entanglement to protect historic in- 
tegrity (Section ||). We describe novel, scalable al- 
gorithms to maintain secure timelines for extended 
time periods and for very large data collections. Fi- 
nally, we evaluate the performance characteristics of 
Timeweave in Section || and show that it efficiently 
supports large-sized groups of frequently entangled 
services — up to several hundred — with maintenance 
overhead that does not surpass 2-8% of the compu- 
tational resources of a PC-grade server. 



2 Background 

In this work we draw on results from research on se- 
cure time stamping and authenticated dictionaries. 
The main inspiration behind our approach comes 



from Lamport's classic logical clock paradigm 1 14 



2.1 Secure Time Stamping 

In secure time stamping, it is the responsibility of 
a centralized, trusted third party, the Time Stamp- 
ing Service (TSS), to maintain a temporal ordering 
of submission among digital documents. As doc- 
uments or document digests are submitted to it, 
the TSS links them in a tamper-evident chain of 
authenticators, using a one-way hash function, and 
distributes portions of the chain and of the authenti- 
cators to its clients. Given the last authenticator in 
the chain it is impossible for anyone, including the 
TSS, to insert a document previously unseen in the 
middle of the chain unobserved, without significant 
collusion, and without finding a second pre-image 
for the hash function used J ll| . 

Benaloh and de Mare |5| describe synchronous, 
broadcast-based time stamping schemes where no 
central TSS is required, and introduce the concept 



of a time stamping round. All documents time 
stamped during a round are organized in a data 
structure, flat or hierarchical, and yield a collec- 
tive digest that can be used to represent all the 
documents of the entire round, in a tamper-evident 
manner; given the digest, the existence of exactly 
the documents inside the data structure can be 
proved succinctly, and any document outside the 
data structure can be proved not to be there. 

Buldas et al. Q extend previous work by signifi- 
cantly diminishing the need to trust the TSS. They 
also introduce efficient schemes for maintaining rela- 
tive temporal orderings of digital artifacts with log- 
arithmic complexity in the total number of artifacts. 
A large, concurrent project towards the full speci- 
fication of a time stamping service is described by 
Quisquater et al. pl[ . 

Ansper et al. [g| discuss time stamping service 
availability, and suggest a scheme similar to consen- 
sus in a replicated system to allow for fault-tolerant 
time stamping. 

2.2 Authenticated Dictionaries 

Authenticated dictionaries are data structures that 
operate as tamper-evident indices for a dynamic 
data set. They help compute and maintain a one- 
way digest of the data set, such that using this digest 
and a succinct proof, the existence or non-existence 
of any element in the set can be proved, without 
considering the whole set. 

The first such authenticated dictionary is consid- 
ered to be an unanticipated use of Merkle's hash 
trees 0, a digital signature scheme. Hash trees 
are binary trees in whose leaves the data set ele- 
ments are placed. Each leaf node is labeled with 
the hash of the contained data element and each 
interior node is labeled with a hash of the concate- 
nated labels of its children. The label of the root 
node is a tamper-evident digest for the entire data 
set. The existence proof for an element in the tree 
consists of the necessary information to derive the 
root hash from the element in question; specifically, 
the proof consists of all labels and locations (left or 
right) of all siblings of nodes on the path from the 
element to the tree root. 

Tree-based authenticated dictionaries reminiscent 
of Merkle's hash trees have been most notably used 
for the distribution of certificate revocation records, 
first by Kocher JH|, and then in an incrementally 
updatable version by Naor and Nissim ]lS|j . Bul- 
das et al. have obviated the need for trusting the 
dictionary maintainer to keep the dictionary sorted, 
by introducing the authenticated search tree J|, (jj. 
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Authenticated search trees are like hash trees, but 
all nodes, leaves and internal nodes alike, contain 
data set elements. The label of the node is a hash 
not only of the labels of its children, but also of the 
element of the node. Existence proofs contain node 
elements in addition to nodes' siblings' labels on the 
path from the element in question to the root. In 
this manner, an existence proof follows the same 
path that the tree maintainer must take to find a 
sought element; as a result, clients need not uncon- 
ditionally trust that the tree maintainer keeps the 
tree sorted, since given a root hash, there is a unique 
descent path that follows the standard traversal of 
search trees towards any single element. 

Authenticated dictionaries have also been pro- 
posed based on different data structures. Buldas 
et al. H describe several tree-like "binary linking 
schemes." Goodrich ct al. @ propose an authenti- 
cated skip list that relies on commutative hashing. 

In the recent literature, the maintenance of au- 
thenticated but persistent dynamic sets ||, p. 294] 
has received some attention. Persistent dynamic 
sets allow modifications of the elements in the 
set, but maintain enough information to recreate 
any prior version of the set. Anagnostopoulos et 
al. [[l] propose and implement persistent authenti- 
cated skip lists, where not only older versions of the 
skip list are available, but they are each, by them- 
selves, an authenticated dictionary. In the same 
work, and also in work by Maniatis and Baker [fl6|| , 
persistent authenticated dictionaries based on red- 
black trees are sketched in some detail, although the 
resulting designs are different. Specifically, in the 
former work, although multiple versions of the au- 
thenticated red-black tree are maintained, the col- 
lection of versions is itself not authenticated; the 
latter work uses a second, non-persistent authenti- 
cated dictionary to authenticate the tree versions. 



3 Secure Timelines 

We define a secure timeline within a service domain. 
A service domain comprises a system offering a par- 
ticular service — the service of the domain — and a 
set of clients who use that system for that service — 
the clients of the domain. Such a service domain 
could be, for example, the file server and all clients 
of a secure file system, or an enterprise-wide certi- 
fication authority along with all certificate subjects 
within that enterprise. 

Within the context of a service domain, a secure 
timeline is a tamper-evident, temporally-ordered, 
append-only sequence of the states taken by the ser- 



vice of that domain. In a sense, a secure timeline 
defines an authenticated logical clock for the service. 
Each time step of the clock is annotated with the 
state in which the service is at the time, and an au- 
thenticator. The authenticator is tamper-evident: 
given the authenticator of the latest time step of 
the timeline, it is intractable for the service or for 
any other polynomially-bound party to "change his- 
tory" unobtrusively by altering the annotations or 
authenticators of past time steps. 

In this work, we consider secure timelines based 
on one-way (second pre-image-resistant) hash func- 
tions. Assuming, as is common, that one-way hash 
functions exist, we use such functions to define the 
"arrow of time." In other words, given a presum- 
ably one-way hash function h such as SHA-1 ]19[| , if 
b = h(a), then we conclude that value a was known 
before value b, or a precedes 6, since given b the 
probability of guessing the right a is negligible. 

A simple recursive way to define a secure time- 
line is as follows: if at logical time i the clock has 
authenticator X^, then at the next logical time step 
i + 1, the hash function h is applied to the previ- 
ous clock authenticator Ti and to the current state 
of the system Si. Assuming that / is a one-way 
digest function from system states to digests, then 
T i+ i = h(i\\Ti\\f(Si)), where || denotes concatena- 
tion. Given Tj_|_i, it is intractable to produce ap- 
propriate a such that Ti+\ — /i(i||T, ||a), so as to 
make an arbitrary authenticator T/ ^ Ti appear 
as the timeline authenticator of logical step i, from 
the second pre-image resistance of the hash func- 
tion. Similarly, for a given T i+1 only a unique state 
digest di = f(Si) is probable, and, from the one- 
way property of the state digest function /, only a 
unique system state Si is probable. Therefore, au- 
thenticator Ti + i is, in a sense, a one-way digest of 
all preceding authenticators and system states, as 
well as of their total temporal ordering. 

Many existing accountable services match the se- 
cure timeline paradigm, since secure timelines are 
a generalization of secure time stamping services 
(TSS) [0. The service state of a TSS is an au- 
thenticated dictionary of all document digests sub- 
mitted to it during a time stamping round. The Key 
Archival Service (KAS) by Maniatis and Baker [|16| 
is another service with a timeline, where the service 
state is now a persistent authenticated dictionary 
of all certificates and revocation records issued by a 
Certification Authority. Similarly, any service that 
maintains one-way digests of its current state can 
be retrofitted to have a secure timeline. Consider, 
for example, Kocher's Certificate Revocation Trees 
(CRT) 1 13 . The state of the service at the end of 
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Figure 1 : The first few steps of a secure timeline. Time 
flows from left to right. Note that the current authen- 
ticator of the timeline is an input to the next state of 
the sys tem . We explain one way to accomplish this in 
Section 5.2. 



each publication interval consists of a hash-tree of 
all published revocation records. The root hash of 
the CRT is a one-way digest of the database. Conse- 
quently, a secure timeline for the revocation service 
can easily follow from the above construction. 

Figure |l| illustrates the first few time steps of a 
secure timeline. In the figure, the new timeline 
authenticator is also fed into the new state of the 
system. Depending on the definition of the state 
digest function, a new state of the service can be 
shown to be fresh, i.e., to have followed the com- 
putation of the authenticator for the previous time 
step. In Time Stamping Services, this places the 
time stamp of a document between two rounds of 
the service. In the Key Archival Service, this bounds 
the time interval during which a change in the Cer- 
tification Authority (new certificate, revocation, or 
refresh) has occurred. In a CRT timeline system, 
this bounds the time when a revocation database 
was built. Some authenticated dictionaries can be 
shown to be fresh(e.g., [pj), and we explain how we 
handle freshness in Section 



5.2 



Secure timelines can be used to answer two basic 
kinds of questions: existence questions and temporal 
precedence questions. Existence questions are of the 
form "is S the i-th system state?" Existence ques- 
tions can be used to establish that the service exhib- 
ited a certain kind of behavior at a particular phase 
in its history. In the time stamping example, an 
existence question could be "is d the round hash at 
time i?" A positive answer allows a client to verify 
the validity of a time stamp from round i, since time 
stamps from round i are authenticated with the root 
hash of that round. Temporal precedence questions 
are of the form "did state S occur before state 5'?" . 



In time stamping, answers to precedence questions 
can establish precedence between two time stamped 
documents. 

Answers to both existence and temporal prece- 
dence questions are provable. Given the last au- 
thenticator in the timeline, to prove the existence 
of a state in the timeline's past I have to produce 
a one-way path — a sequence of applications of one- 
way functions — from that state to the current time- 
line authenticator. Similarly, to prove that state S 
precedes state S', I have to show that there exists a 
one-way path from state S to state S', which means 
that the former must precede the latter. For ex- 
ample, in Figure [l], the path from So to T\ to S% 
is one-way and establishes that state Sq occurred 
before S%. Extending this path to T3 provides an 
existence proof for state Sq, if the verifier knows 
that T3 is the latest timeline authenticator. 

Secure timelines are a general mechanism for tem- 
poral authentication. As with any other authentica- 
tion mechanism, timeline proofs are useful only if 
the authenticator against which they are validated 
is itself secure and easily accessible to all verifiers, 
i.e., the clients within the service domain. In other 
words, clients must be able to receive securely au- 
thenticator tuples of the form (z,Tj) from the ser- 
vice at every time step, or at coarser intervals. This 
assumes that clients have a means to open authen- 
ticated channels to the service. Furthermore, there 
must be a unique tuple for every time step i. Ei- 
ther the service must be trusted by the clients to 
maintain a unique timeline, or the timeline must 
be periodically "anchored" on an unconditionally 
trusted write-once publication medium, such as a 
paper journal or popular newspaper. The latter 
technique is used by some commercial time stamp- 
ing services pij ], to reduce the clients' need to trust 
the service. 

For the remainder of this paper, "time i" means 
the state of the service that is current right after 
timeline element i has been published, as well as 
the physical time period until the publication of the 
timeline authenticators for time step i+ 1. For ser- 
vice A, we denote time i as (A,i). Furthermore, we 
denote the i-th timeline authenticator of service A 
as Tf- and the precedence proof from ^4's time i to 
j as P A 'f , when multiple services are discussed. 



4 Timeline Entanglement 

In the previous section, we described how a secure 
timeline can be used by the clients within a service 
domain to reason about the temporal ordering of 
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the states of the service in a provable manner. In 
so doing, the clients of the service have access to 
tamper-proof historic information about the opera- 
tion of the service in the past. 

However, the timeline of service A does not carry 
much conviction before a client who belongs to a dif- 
ferent, disjoint service domain B, i.e., a client who 
does not trust service A or the means by which it is 
held accountable. Consider an example from time 
stamping where Alice, a client of TSS A, wishes to 
know when Bob, a client of another TSS B, time 
stamped a particular document T>. A time stamp- 
ing proof that links V to an authenticator in B's 
timeline is not convincing to Alice, since she has no 
way to compare temporally time steps in J5's time- 
line to her own timeline, held by A. 

This is the void that timeline entanglement fills. 
Timeline entanglement creates a provable temporal 
precedence from a time step in a secure timeline to 
a time step in another independent timeline. Its 
objective is to allow a group of mutually distrustful 
service domains to collaborate towards maintaining 
a common, tamper-proof history of their collective 
timelines that can be verified from the point of view 
(i.e., within the trust domain) of any one of the 
participants. 

In timeline entanglement, each participating ser- 
vice domain maintains its own secure timeline, but 
also keeps track of the timelines of other partici- 
pants, by incorporating authenticators from those 
foreign timelines into its own service state, and 
therefore its own timeline. In a sense, all partici- 
pants enforce the commitment of the timeline au- 
thenticators of their peers. 

In Section 4.1, we define timeline entanglement 
with illustrative examples and outline its properties. 
We then explore in detail three aspects of timeline 
entanglement: Secure Temporal Mappings in Sec- 
tion 4.2 , the implications of dishonest timeline main- 



tainors in Section 4.3, and Historic Survivability in 
Section fO. 



4.1 Fundamentals 

Timeline entanglement is defined within the context 
of an entangled service set. This is a dynamically 
changing set of service domains. Although an entan- 
gled service set where all participating domains offer 
the same kind of service is conceivable — such as, for 
example, a set of time stamping services — we envi- 
sion many different service types, time stamping ser- 
vices, certification authorities, historic records ser- 
vices, etc., participating in the same entangled set. 
We assume that all participating services know the 



current membership of the entangled service set, al- 
though inconsistencies in this knowledge among ser- 
vices does not hurt the security of our constructs 
below. We also assume that members of the service 
set can identify and authenticate each other, either 
through the use of a common public key infrastruc- 
ture, or through direct out-of-band key exchanges. 

Every participating service defines an indepen- 
dent sampling method to select a relatively small 
subset of its logical time steps for entanglement. 
For example, a participant can choose to entangle 
every n-th time step, although other sampling meth- 
ods are certainly not precluded. At every time step 
picked for entanglement, the participant sends an 
authenticated message that contains its signed logi- 
cal time and timeline authenticator to all other par- 
ticipants in the entangled service set. This message 
is called a timeline thread. A timeline thread sent 
from A at time (A, i) is denoted as tf and has the 
form [A, i, 7^ A , a A {A, i, T t A }}. a A {X} represents A's 
signature on message X. 

When participant B receives a correctly signed 
timeline thread from participant A, it verifies the 
consistency of that thread with its local view of 
collective history and then archives it. Thread tf 
is consistent with B's local view of collective his- 
tory if it can be proved to be on the same one-way 
path (hash chain) as the last timeline authenticator 
of A that B knows about (see Figure |). Towards 
this goal, A includes the necessary temporal prece- 
dence proof, as described in Section || along with 
the thread that it sends to B. In the figure, when 
thread tf reaches B, the most recent timeline au- 
thenticator of A that B knows is T A . Along with the 
thread, A sends the precedence proof P,'f from its 
time (A, I) to time (A,i). As a result, B can verify 
that the new thread carries a "legitimate" timeline 
authenticator from A, one consistent with history. 
If everything checks out, B archives the new time- 
line authenticator and associated precedence proof 
in its local thread archive. 

A thread archive serves two purposes: first, it 
maintains a participant's local knowledge of the his- 
tory of the entangled service set. Specifically, it 
archives proof that every participant it knows about 
maintains a consistent timeline. It accomplishes 
this by simply storing the threads, which are snap- 
shots in the sender's timeline, and supporting prece- 
dence proofs, which connect these snapshots in a 
single one-way chain. The second purpose of the 
thread archive is to maintain temporal precedence 
proofs between every foreign thread it receives and 
local timeline steps. It accomplishes this by con- 
structing a one-way digest of its contents, which is 
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that B returns to A for the entanglement of thread 
tf consists of three components: first, a precedence 
proof Pg'l 1 from the last of -B's timeline authen- 



Figure 2: Entanglement exchanges between partici- 
pants A and B. The workings of B are shown in detail. 
We show two entanglement exchanges, one of time {B, k) 
with time {A, I), and one of time (A,i) with time (B,j). 
Thick black horizontal arrows show timeline thread mes- 
sages. Thin black horizontal arrows show entanglement 
receipt messages. Vertical black arrows show one-way 
operations. The thick shadowed arrow shows the tem- 
poral ordering effected by thread tf and its receipt r^'j. 



then used along with the system state digest, to de- 
rive the next local timeline authenticator; the mod- 
ified recursive definition of timeline authenticators 
is = h(i\\T t A \\h{f(S?)\\g{E?))), where g is the 
one-way digest function for the thread archive, and 
E A is the current versio n of the thread archive at 
time (A, i). See Section 5.2 for details on a data 



structure capable of fulfilling these requirements. 

Participant B responds to the newly reported 
timeline authenticator with an entanglement receipt. 
This receipt proves that the next timeline authen- 
ticator that B produces is influenced partly by the 
archiving of the thread it just received. The re- 
ceipt must convince A of three things: first, that its 
thread was archived; second, that the thread was 
archived in the latest — "freshest" — version of -B's 
thread archive; and, third, that this version of the 
thread archive is the one whose digest is used to 
derive the next timeline authenticator that B pro- 
duces. As a result, the entanglement receipt r 



T? x ; second 
thread tf in the latest version Ef_, 



ticators that A knows about, Tjf , to -B's timeline 
authenticator right before archiving A's new thread 
an existence proof for the timeline 
of B's thread 

archive, as modified after time (B, j — 1) (the equiv- 
alent of an undeniable attester in JtJ — see also Sec- 
tion 5.2); and, third, a one-way derivation of the 
next timeline authenticator of B from the new ver- 
sion of the thread archive, i.e., the one-way digest 
f(Sf_i) of the current system state. It is now A's 
turn to check the validity of the proofs in the en- 
tanglement receipt. If all goes well, A stores the 
proof of precedence and reported timeline authenti- 
cator from B in its receipt archive. This concludes 
the entanglement process from time {A, i) to time 
(B,j). 

The receipt archive is similar to the thread 
archive; it stores entanglement receipts that the 
participant receives in response to its own time- 
line threads. However, it is not an authenticated 
archive, since it is not necessary to prove to anyone 
whether and when a participant stores the receipts 
received in response to its own timeline threads. 

After the entanglement of time {A, i) with time 
(B,j), both A and B have in their possession 
portable temporal precedence proofs ordering A's 
past before -B's future. Any one-way process at A 
whose result is included in the derivation of TV 4 or 
earlier timeline authenticators at A can be shown 
to have completed before any one-way process at 
B that includes in its inputs or later timeline 
authenticators at B. 

In this definition of timeline entanglement, a par- 
ticipating service entangles its timeline at the prede- 
termined sample time steps with all other services 
in the entangled service set (we call this all-to-all 
entanglement). In this work we limit the discus- 
sion to all-to-all entanglement only, but we describe 
a more restricted, and consequently less expensive, 
entanglement model in future work (Section 0) . 

The primary benefit of timeline entanglement is 
its support for secure temporal mapping. A client 
in one service domain can use temporal information 
maintained in a remote service domain that he does 
not trust, by mapping that information onto his own 
service domain. This mapping results in some loss 
of temporal resolution — for example, a time instant 
maps to a positive-length time interval. We describe 



in- 



secure temporal mapping in Section 4.2. 

Timeline entanglement is a sound method of ex- 
panding temporal precedence proofs outside a ser- 
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vice domain; it does not prove incorrect prece- 
dences. However it is not complete, that is, there 
are some precedences it cannot prove. For exam- 
ple, it is possible for a dishonest service to maintain 
clandestinely two timelines, essentially "hiding" the 
commitment of some of its system states from some 
members of the entangled service set. We explore 
the implications of such behavior in Section |4.3| . 

Finally, we consider the survivability characteris- 
tics of temporal proofs beyond the lifetime of the 



associated timeline, in Section 4.4 



4.2 Secure Temporal Mapping 

Temporal mapping allows a participating service A 
to map onto its own timeline a time step (B, i) from 
the timeline of another participant B. This mapping 
is denoted by (B,i) i— > A. Since A and B do not 
trust each other, the mapping must be secure; this 
means it should be practically impossible for B to 
prove to A that ((B,i) ^ A) = [{A,j),{A,k)], if 
(B,i) occurred before (A,j) or after (A,i). 

Figure |^ illustrates the secure temporal mapping 
(B, 2) i — ► A. To compute the mapping, A requires 
only local information from its thread and receipt 
archives. First, it searches in its receipt archive for 
the latest entanglement receipt that B sent back 
before or at time (B, 2), receipt r^'l in the example. 
As described in Section ||, this receipt proves to A 
that its time (A, 1) occurred before B's time (B, 1). 

Then, A searches in its thread archive for the 
earliest thread that B sent it after or at time 
(B,2), which is thread tf in the example. This 
thread proves to A that its time {A, 5} occurred 
after time (5,3). Recall, also, that when A re- 
ceived tf in the first place, it had also received 
a temporal precedence proof from (B,l) to (5,3), 
which in the straightforward hash chain case, also 
includes the system state digest for (B,2). Now A 
has enough information to conclude that ((5, 2) i— > 
A) = [{A, 4), (A, 5)]. 

Since A has no reason to believe that B maintains 
its timeline in regular intervals, there is no more 
that A can assume about the temporal placement 
of state Sf within the interval [(A, 4), {A, 5)]. This 
results in a loss of temporal resolution; in the figure, 
this loss is illustrated as the difference between the 
length on B's timeline from (B, 2) to (B, 3) (i.e., the 
"duration" of time step (5, 2)) and the length of the 
segment on A's timeline from (A, 4) to (A, 5) (the 
duration of (B,2) i— > A). This loss is proportional 
to the interval between successive thread messages 
between A and B. 4t can be made shorter, but only 
at the cost of increasing the frequency with which A 




Figure 3: Secure mapping of time (B, 2) onto the time- 
line of A. Thick arrows indicate timeline threads. Thin 
arrows indicate entanglement receipts (only the relevant 
entanglement receipts are shown) . Irrelevant thread and 
receipt messages are grayed-out. The dark broken line 
illustrates the progression of values that secure the cor- 
rectness of the mapping. 



and B send threads to each other, which translates 
to more messages and more computation at A and 
B. We explore this trade-off in Section ra. 

Secure time mapping allows clients within a ser- 
vice domain to determine with certainty the tem- 
poral ordering between states on their own service 
and on remote, untrusted service domains. Going 
back to the time stamping example, assume that 
Alice has in her possession a time stamp for docu- 
ment C in her own service domain A, which links it 
to local time (A, 0), and she has been presented by 
Bob with a time stamp on document T> in Bob's ser- 
vice domain 5, which links Bob's document to time 
(B,2). Alice can request from A the time mapping 
(B,j) i — ► A, shown above to be [(A, 1), (A, 5)]. With 
this information, Alice can be convinced that her 
document C was time stamped before Bob's doc- 
ument T> was, regardless of whether or not Alice 
trusts Bob or B. 

In the general case, not all time steps in one time- 
line map readily to another timeline. To reduce the 
length of temporal pre cedence proofs, we use hash 
skip lists (Section [Tl]) instead of straightforward 
hash chains in Timeweave, our prototype. Tempo- 
ral precedence proofs on skip lists are shorter be- 
cause they do not contain every timeline authenti- 
cates from the source to the destination. In time- 
lines implemented in this manner, only time steps 
included in the skip list proof can be mapped with- 
out the cooperation of the remote service. For other 
mappings, the remote service must supply addi- 
tional, more detailed precedence proofs, connecting 
the time authenticator in question to the time au- 
thenticators that the requester knows about. 
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4.3 Historic Integrity 

Timeline entanglement is intended as an artificial 
enlargement of the class of usable, temporal order- 
ing^ that clients within a service domain can deter- 
mine undeniably. Without entanglement, a client 
can determine the provable ordering of events only 
on the local timeline. With entanglement, one-way 
paths are created that anchor time segments from 
remote, untrustcd timelines onto the local timeline. 

However, the one-way properties of the digest and 
hash functions used make timelines secure only as 
long as everybody is referring to the same, single 
timeline. If, instead, a dishonest service A maintains 
clandestinely two or more timelines or branches of 
the same timeline, publishing different timeline au- 
thenticators to different subsets of its users, then 
that service can, in a sense, revise history. Just Jl2| 
identified such an attack against early time stamp- 
ing services. Within a service domain, this attack 
can be foiled by enforcing that the service period- 
ically commits its timeline on a write-once, widely 
published medium, such as a local newspaper or pa- 
per journal. In such a way, when there is doubt, a 
local client can always request a precedence proof 
that links the current timeline authenticator to the 
most recent widely published authenticator. 

Unfortunately, a similar attack can be mounted 
against the integrity of collective history, in an en- 
tangled service set. Entanglement, as described in 
Section |J, does not verify that samples from B's 
timeline that are archived at A and C are identi- 
cal. If B is malicious, it can report authenticators 
from one chain to A and from another to C, unde- 
tected (see Figure |]). In the general case, this does 
not dilute the usability of entanglement among hon- 
est service domains. Instead, it renders unprovable 
some interactions between honest and dishonest ser- 
vice domains. More importantly, attacks by a ser- 
vice against the integrity of its own timeline can 
only make external temporal precedence informa- 
tion involving that timeline inconclusive; such at- 
tacks cannot change the temporal ordering between 
time steps on honest and dishonest timelines. Ulti- 
mately, it is solely the clients of a dishonest service 
who suffer the consequences. 

Consider, for instance, the scenario of Figure |J. 
Dishonest service B has branched off its originally 
unique timeline into two separate timelines at its 
time (-8,2). It uses the top branch, with times 3', 
4', etc., in its entanglements with service C, and its 
bottom branch, with times 3, 4, etc., in its entangle- 
ments with service A. From ^4's point of view, event 
Af is incorporated in B's state and corresponding 
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Figure 4: An example showing a dishonest service B 
that maintains two timelines, entangling one with A and 
another with C. Event Af is committed on the bottom 
branch of B's timeline, but does not appear on the top 
branch. 

timeline at time (5,3). From C's point of view, 
however, event Af seems never to have happened. 
Since Af does not appear in the branch of B's time- 
line that is visible to C, C's clients cannot conclu- 
sively place event Af in time at all. Therefore, it is 
only the client of B who is responsible for event Af 
who suffers from this discrepancy. C does not know 
about it at all, and A knows its correct relative tem- 
poral position. 

We describe briefly a method for enforcing time- 
line uniqueness within an entangled service set in 
Section 0. 

4.4 Historic Survivability 

Historic survivability in the context of an entangled 
set of services is the decoupling of the verifiability 
of existence and temporal precedence proofs within 
a timeline from the fate of the maintainer of that 
timeline. 

Temporal proofs are inherently survivable be- 
cause of their dependence on well-known, one-way 
constructs. For example, a hash chain consisting 
of multiple applications of SHA-1 certainly proves 
that the result of the chain temporally followed the 
input to the chain. However, this survivability is 
moot, if the timeline authenticators that the proof 
orders undeniably can no longer be interpreted, or 
associated with a real time frame. 

Fortunately, secure temporal mapping allows a 
client within a service domain to fortify a tempo- 
ral proof that he cares about against the passing 
of the local service. The client can accomplish this 
by participating in more service domains than one; 
then, he can proactively map the temporal proofs 
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he cares about from their source timeline onto all 
the timelines of the service domains in which he be- 
longs. In this manner, even if all but one of the 
services he is associated with become unavailable or 
go out of business, the client may still associate his 
proofs with a live timeline in the surviving service 
domain. 

Consider, for example, the scenario illustrated in 
Figure |[ David, who belongs to all three service do- 
mains A, B and C, wishes to fortify event N so as 
to be able to place it in time, even if service B is no 
longer available. He maps the event onto the time- 
lines of A and C — "mapping an event A/"" is equiv- 
alent to mapping the timeline time step in whose 
system state event N is included, that is, (B, 2} in 
the example. Even though the event occurred in B's 
timeline, David can still reason about its relative po- 
sition in time, albeit with some loss of resolution, in 
both the service domains of A and C, long after B 
is gone. In a sense, David "hedges his bets" among 
multiple services, hoping that one of them survives. 
The use of temporal mapping in this context is sim- 
ilar in scope to the techniques used by Ansper et 
al. Q for fault-tolerant time stamping services, al- 
though it assumes far less mutual trust among the 
different service domains. 



5 Implementation 

We have devised two new, to our knowledge, disk- 
oriented data structures for the implementation of 
Timeweave , ou r timeline entanglement prototype. 
In Section 5.1, 



we present authenticated append- 
only skip lists. These are an efficient optimization of 
traditional hash chains and yield precedence proofs 
with size proportional to the square logarithm of 
the total elements in the list, as opposed to linear. 
In Section 5.2, we present RBB-Trees, our disk- 



based, persistent authenticated dictionaries based 
on authenticated search trees. RBB-Trees scale to 
larger sizes than current in-memory persistent au- 
thenticated dictionaries, while making efficient use 
of the disk. Finally, in Section 5.3, we outline how 
Timeweave operates. 



5.1 Authenticated 
Lists 



Append-only Skip 



Our basic tool for maintaining an efficient secure 
timeline is the authenticated append-only skip list. 
The authenticated append-only skip list is a mod- 
ification of the simplistic hash chain described in 




Figure 5: An example of mapping event Af onto two 
other timelines, to obtain a survivable proof of its tem- 
poral position. The top shaded line represents (Af i— > A) 
and the bottom shaded line represents (Af C). 



Section |^ that yields improved access characteris- 
tics and shorter proofs. 

Our skip lists are deterministic, as opposed to the 
randomization used in most skip lists proposed in 
the literature [^0). Unlike the authenticated skip 
lists introduced by Goodrich et al. pC| |, our skip lists 
are append-only, which obviates the need for com- 
mutative hashing. Every list clement has a numeric 
identifier that is a counter from the first element 
of the list (the first element is element 1 , the tenth 
element is element 10, and so on). Every element 
carries a data value and an authenticator, similarly 
to what was suggested in Section || for single-chain 
timelines. 

The skip list consists of multiple parallel hash 
chains at different levels of detail, each containing 
half as many elements as the previous one. The ba- 
sic chain (at level 0) links every element to the au- 
thenticator of the one before it, just like simple hash 
chains. The next chain (at level 1) coexists with 
the level chain, but only contains elements whose 
numeric identifiers are multiples of 2, and every el- 
ement is linked to the element two positions before 
it. Similarly, only elements with numeric identifiers 
that are multiples of 2 1 are contained in the hash 
chain of level i. No chains of level j that is higher 
than log 2 n are maintained, if all elements are n. 

The authenticator Ti of element i with data value 
di is computed from a hash of all the partial au- 
thenticators (called links) in each basic hash chain 
in which it participates — we share the notation from 
Section ^ for data values and authenticators here. 
Element i participates in l + l chains, where i = 2'fc, 
and 2 does not divide k (in other words, I is the 
exponent of 2 in the factorization of i), therefore 
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Figure 6: Six consecutive skip list elements, element 16 
to element 21. Arrows show hash operations from pre- 
vious authenticators to links of an element. The top of 
each tower is the resulting authenticator for the element, 
derived by hashing together all links underneath it. 

element i has the I + 1 links L\ = h(i,j,di,Ti_ 2 j), 
< j < I, and authenticator T t = h(L°\\ . . . ||L|). 
Figure ^| illustrates a portion of such a skip list. In 
the implementation, we combine together the cle- 
ment authenticator with the 0-th level link for odd- 
numbered elements, since such elements have a sin- 
gle link, which is sufficient as an authenticator by 
itself. 

Skip lists allow their efficient traversal from an 
element i to a later element j in a logarithmic num- 
ber of steps: starting from element i, successively 
higher-level links are utilized until the "tallest ele- 
ment" (one with the largest power of 2 in its fac- 
tors among all element indices between i and j) is 
reached. Thereafter, successively lower-level links 
are traversed until j is reached. More specifically, 
an iterative process starts with the current element 
c = i. To move closer to the destination element 
with index j, the highest power 2 l of 2 that divides 
c is picked, such that c + 2 Z < j. Then element 
k = c + 2 Z becomes the next current element c in 
the traversal. The iteration stops when c = j. 

The associated temporal precedence proof linking 
element i before element j is constructed in a man- 
ner similar to the traversal described above. At ev- 
ery step, when a jump of length 2 Z is taken from the 
current element c to k = c + 2 Z , the element value of 
the new element dk is appended to the proof, along 
with all the associated links of element k, except for 
the link at level z. Link L| is omitted since it can 
be computed during verification from the previous 
authenticator T c and the new value dk- 

In the example of Figure ^, the path from el- 
ement 17 to element 21 traverses elements 18 
and 20. The corresponding precedence proof 
from element 17 to element 21 is = 



{d\%, L\ 8 ; d 2 o, -&20' ^io> ^2i}- With this proof and 
given the authenticators T±? and T21 of elements 
17 and 21 respectively, the verifier can succes- 
sively compute T{ 8 = /i(/i(18||0||di 8 ||T 17 )|iL} 8 )), 
thenT^ = /i(L^ ||/i(20||l||d 20 ||T 1 ' 8 ||L| )) and finally 
T21 = /i(21[[Q[|<fci||T^ )— recall that for all odd ele- 
ments i, Ti = Lf. If the known and the derived 
values for the authenticator agree (T21 = T^), then 
the verifier can be convinced that the authentica- 
tor Tn preceded the computation of authenticator 
T21, which is the objective of a precedence proof, 
as long as the verifier believes that finding a sec- 
ond pre-image for the hash function h has negligible 
probability. 

Thanks to the properties of skip lists, the length 
of any of these proofs contains roughly a logarith- 
mic number of authenticators, links and values in 
the total number of elements in the timeline. The 
worst-case proof for a skip list of n elements tra- 
verses 2 x log 2 (n) elements, climbing links of every 
level between and log 2 (n) and back down again, or 
log 2 (n.) link values total. Assuming that every link 
and value is a SHA-1 digest of 160 bits, the worst 
case proof for a timeline of a billion elements is no 
longer than 20 KBytes, and most are much shorter. 

Our skip lists are fit for secondary storage. They 
are implemented on memory-mapped files. Since 
modifications are expected to be relatively rare, 
compared to searches and proof extractions, we al- 
ways write changes to the skip list through to the 
disk immediately after they are made, to maintain 
consistency in the face of machine crashes. We do 
not, however, support structural recovery from disk 
crashes; we believe that existing file system and re- 
dundant disk array technologies are adequate to pre- 
vent and recover all but the most catastrophic losses 
of disk bits. 

5.2 Disk-based Persistent Authenti- 
cated Dictionaries 

This work uses authenticated persistent dictionaries 
based on trees. A persistent dictionary maintains 
multiple versions (or snapshots) of its contents as 
it is modified. In addition to the functionality of- 
fered by simple authenticated dictionaries, it can 
also provably answer questions of the form "in snap- 
shot t, was element d in the dictionary?" . Further- 
more, the authenticated labels for every individual 
snapshot must also be maintained. 

The dictionaries we used in this work can poten- 
tially grow very large, much larger than the sizes 
of current main memories. Therefore, we have ex- 
tended our earlier work on balanced persistent au- 
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Figure 7: An RBB-Tree. Boxes are disk blocks. In this 
example, each non-root disk block contains a minimum 
of 1 and a maximum of 3 keys. The authentication labels 
of the embedded binary tree nodes are not shown; for 
any key node, its label consists of the hash of the label of 
its left child, its own key, and the label of its right child, 
as in Furthermore, we do not show the "color" 

attribute of the keys in the per-node Red-Black trees, 
since they have no bearing in our discussion. 



thenticated search trees jL6| to design on-disk per- 
sistent authenticated dictionaries. The resulting 
data structure, the RBB-Tree, is a binary authen- 
ticated search tree ^] embedded in a persistent 
B-Tree [||, Ch. 18]. Figure | shows a simple RBB- 
Tree holding 16 numeric keys. 

RBB-Trees, like B-Trees, are designed to organize 
keys together in efficient structures that result in few 
disk accesses per tree operation. Every tree node is 
stored in its own disk block, contains a minimum of 
r— 1 and a maximum of 2r — 1 keys, and has between 
r and 2r children (the root node is only required to 
have between 1 and 2r — 1 keys) . 

Unlike traditional B-Trees, RBB-Tree nodes do 
not store their keys in a flat array. Instead, keys 
within RBB nodes are organized in a balanced bi- 
nary tree, specifically a Red-Black tree |||| Ch. 
13]. We consider RBB-Trees "virtual" binary trees, 
since the in-node binary trees connected to each 
other result in a large, piecewise Red-Black tree, 
encompassing all keys in the entire dictionary. 

It is this "virtual" binary tree of keys that is au- 
thenticated, in the sense of the authenticated search 
trees by Buldas et al. [^,0. As such, the security 
properties of RBB-Trees are identical to those of au- 
thenticated search trees, including the structure of 
existence/non-existence proofs. 

Since the RBB-Tree is a valid B-Tree, it is effi- 
cient in the number of disk block accesses it requires 
for the basic tree operations of insertion, deletion 
and modification. Specifically, each of those oper- 
ations takes O(log r n) disk accesses, where n is the 



total number of keys in the tree. Similarly, since 
the internal binary tree in each RBB-Tree node is 
balanced, the virtual embedded binary tree is also 
loosely balanced, and has height 0((log r n)(log 2 r)), 
that is, 0(log 2 n) but with a higher constant factor 
than in a real Red-Black tree. These two collabo- 
rating types of balancing applied to the virtual bi- 
nary tree — the first through the blocking of keys in 
RBB nodes, and the second through the balancing 
of the key nodes inside each RBB node — help keep 
the length of the resulting existence/non-existence 
proofs also bounded to 0(\og 2 n) elements. 

The internal key structure imposed on RBB-Tree 
nodes does not improve the speed of search through 
the tree over the speed of search in an equivalent 
B-Tree, but limits the length of existence proofs 
immensely. The existence proof for a datum in- 
side an authenticated search tree consists of the 
search keys of each node from the sought datum 
up to the root, along with the labels of the siblings 
of each of the ancestors of the sought datum up 
to the root. In a very "bushy" tree, as B-Trees 
are designed to be, this would mean proofs con- 
taining authentication data from a small number 
of individual nodes; unfortunately, each individual 
node's authentication data consist of roughly r keys 
and r siblings' labels. For example, a straightfor- 
wardly implemented authenticated B-Tree storing 
a billion SHA-1 digests with r — 100 yields exis- 
tence proofs of length |~log r 10 9 ] x (r x (160 + 160)) 
bits, or roughly 160 KBits. The equivalent Red- 
Black tree yields existence proofs of no more than 
2 x [log 2 10 9 ] x (160+ 160) bits, or about 18 KBits. 
RBB-Trees seek to trade off the low disk access costs 
of B-Trees with the short proof lengths of Red-Black 
trees. The equivalent RBB-Tree of one billion SHA- 
1 digests yields proofs no longer than 
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[log r 10 9 ] x 2 x [log 2 r] x (160 + 160) 

bits or roughly 22 KBits, with disk access costs iden- 
tical to those of the equivalent B-Tree. 

We have designed dynamic set persistence ||, p. 
294] at the granularity of both the RBB-Node and 
the embedded key node (see Figure |J). Each RBB 
node allows a small number of persistent versions of 
itself. When all the available version slots or all the 
available key slots of the RBB-node are exhausted, 
a new one is created, containing only the latest key 
tree snapshot. 

The different persistent snapshot roots of the 
RBB-Tree are held together in an authenticated 
linked list — in fact, we use our own append-only au- 
thenticated skip list from Section 5.1. 
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Figure 8: A detail from the tree of Figure ^ illustrating 
dynamic set persistence. The hollow arrows inside the 
RBB nodes denote the different version slots of each 
node (up to three in this example). Version 2 is identical 
to that of the original tree shown before. Version 3 is 
version 2 after key 18 is removed. As a result, a new 
key node 15' is created and, similarly, a new key node 
12' is created. Version 4 is version 3 after key 19 is 
inserted. The RBB node previously holding 14 and 15' 
had no more room for key nodes, so a new RBB node was 
created to hold the new key nodes 14', 15" and 19. At 
the bottom, the snapshot root skip list is shown. Nodes 
that change in a snapshot use the skip list authenticator 
of the previous snapshot as their NIL value, to preserve 
the "freshness" of the snapshot. 



Since each snapshot of the RBB-Tree is a "vir- 
tual" binary authenticated search tree, the root la- 
bel of that tree (i.e., the label of the root key node of 
the root RBB node) is a one-way digest of the snap- 
shot H Furthermore, the authenticated skip list 
of those snapshot root labels is itself a one-way di- 
gest of the sequence of snapshot roots. As a result, 
the label of the last element of the snapshot root 
skip list is a one-way digest of the entire history of 
operations of the persistent RBB-Tree. The snap- 
shot root skip list subsumes the functionality of the 
Time Tree in our earlier persistent authenticated 
Red-Black tree design Q . 

We piggy-back the disk location of the snapshot 
root along with the snapshot root label as the data 
value in every skip list element; however only snap- 
shot root labels participate in skip list authentica- 
tor and link computation, since the particular disk 
location of a snapshot root need not be proved to 
anyone. 

In some cases the "freshness" of an authenticated 
dictionary snapshot has to be provable. For ex- 
ample, in our description of secure timelines, we 
have specified that the system state must depend 



on the authenticator of the previous timeline time 
step. When the system state is represented by an 
authenticated dictionary, an existence proof within 
that dictionary need not only show that a sought 
element is part of the dictionary given the dictio- 
nary digest (root hash), but also that the sought 
element was added into the dictionary after the au- 
thenticator of the previous time step was known. 
As with other authenticated dictionaries, we accom- 
plish this by making the hash label of NIL point- 
ers equal to the "freshness" authenticator, so that 
all existence proofs of newly inserted elements — 
equivalently, non-existence proofs of newly removed 
elements — prove that they happened after the given 
freshness authenticator was known. Note that sub- 
trees of the RBB-Tree that do not change across 
snapshots retain their old freshness authenticators. 
This is acceptable, since freshness is only necessary 
to prove to a client that a requested modification 
was just performed (for example, when we produce 
entanglement receipts in Section ^) , and is required 
only of newly removed or inserted dictionary ele- 
ments. 

In standalone RBB-Trees, the freshness authenti- 
cator is simply the last authenticator in the snap- 
shot root list (i.e., the authenticator that resulted 
from the insertion of the latest closed snapshot root 
into the skip list). In the RBB-Trees that we use 



for thread archives in Timeweave (Section 5.3), the 
freshness authenticator is exactly the authenticator 
of the previous timeline time step. 

5.3 Timeweave 

Timeweave is an implementation of the timeline en- 
tanglement mechanisms described in Section || It is 
built using our authenticated append-only skip lists 
(Section 5.1) and our on-disk persistent authenti- 
cated search trees (Section |T^) . 

A Timeweave node maintains four components: 
first, a service state, which is application specific, 
and the one-way digest mechanism thereof; second, 
its secure timeline; third, a persistent authenticated 
archive of timeline threads received; and, fourth, a 
simple archive of entanglement receipts received. 

The archive of timeline threads is also an authen- 
ticated dictionary, but persistent in this case. The 
data stored in the dictionary are timeline threads 
for incoming threads, and timeline thread receipts 
for outgoing threads. The data are ordered by the 
identity of the remote service in the thread opera- 
tion, and then by the foreign logical time associated 
with the thread operation. The dictionary is im- 
plemented as an RBB-Tree and has a well-defined 
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mechanism for calculating its one-way digest, de- 
scribed in Section [T^. 

Finally, the timeline itself is stored as an append- 
only authenticated skip list. The system digest used 
to derive the timeline authenticator at every logical 
time step is a hash of the concatenation of the ser- 
vice state digest and the digest of the thread archive 
after any incoming and outgoing threads have been 
recorded. 

The main operational loop of a Timcwcavc ma- 
chine is as follows: 

1 . Handle client requests and update system state 
digest f(S). 

2. Insert all valid incoming timeline threads into 
thread archive E and update thread archive di- 
gest g(E). 

3. Hash together the digests to produce system 
digest d = h(f(S)\\g(E)). 

4. Append d into the timeline skip list, resulting 
in a new timeline authenticator T, and sign the 
authenticator. 

5. For all incoming timeline threads just archived, 
construct and return receipts to thread senders. 

6. If it is time to send an outgoing timeline thread, 
send one to all peers, and store the receipts in 
the receipt archive. 

The Timeweave machine also allows clients to 
request local temporal mappings of remote logi- 
cal times and temporal precedences between local 
times. 



6 Evaluation 

In this section, we evaluate the performance char- 
acteristics of timeline entanglement. First, in Sec- 
tion [O , we present measurements from a Java im- 
plementation of the Timeweave infrastructure: au- 
thenticated appe nd-o nly skip lists and RBB-Trees. 
Then, in Section 6.2, we explore the performance 
characteristics of the system as a function of the two 
basic Timeweave system parameters, entanglement 
frequency, and entangled service set size. 

In all measurements, we use a lightly loaded 
dual Pentium III Xeon computer at 1 GHz, with 
2 GBytes of main memory, running RedHat Linux 
7.2, with the stock 2.4.9-13smp kernel and Sun Mi- 
crosystems' JVM 1.3.02. The three disks used in 
the experiments are model MAJ3364MP made by 
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Figure 9: Skip list performance, (a) Append time vs. 
list size. "Global average" shows average performance 
over all operations; "last average" shows performance 
during the last 100,000 operations for a given size; and 
"no hash" shows the same information as "last average" 
but excludes hashing operations, (b) Search time vs. list 
size. "Existence" shows searches from a random element 
to the end of the list, and "precedence" shows searches 
between two random elements. 



Fujitsu, which offer 10,000 RPMs and 5 ms aver- 
age seek time. We devote 1 GByte of main mem- 
ory to each experiment, for in- memory caching and 
disk block caching alike. We use a block size of 
16 KBytes, which fixes the order of RBB-Trees to 
r = 145. Finally, for signing we use DSA with SHA- 
1, with a key size of 1024 bits. 

6.1 Data Structure Performance 

We measure the raw performance characteristics of 
our disk-based authenticated data structures. Since 
Timeweave relies heavily on these two data struc- 
tures, understanding their performance can help 
evaluate the performance limitations of Timeweave. 

Figure ^(a) shows the performance of skip list ap- 
pends, for skip list sizes ranging from 100,000 to 
100 million elements, in 100,000 element increments. 
The figure graphs average time taken by an append 
over all operations alongside append times averaged 
over the "last" few operations (100,000 last appends 
for each size plotted). Late appends cost marginally 
more than the average append operation. The fig- 
ure also shows the time taken per append excluding 
hash operations. Although more data are hashed 
during appends of larger skip lists, the graph shows 
that the difference is indistinguishable compared to 
the setup time of the Java hashing machinery. 

We also measure the performance of skip list 
searches, in Figure ||(b). We ran 10,000 random 
existence search trials per size and 10,000 random 
precedence search trials per size. A random exis- 
tence search picks a random element in the list and 
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Figure 10: RBB-Tree performance for different snap- 
shot sizes. Curve labels indicate the number of keys per 
snapshot — from 100 keys to 1 million keys per snapshot, 
(a) Insertion time vs. tree size, (b) Search time vs. tree 
size. 



Keys per snapshot 


100 


IK 


10K 


100K 


1M 


Tree Size (GB) 


64 


45 


24 


4 


0.5 



Table 1 : Tree size on disk as a function of the snapshot 
size used to build it. Sizes shown correspond to trees 
with three million keys. 



finds a proof from that element to the end of the 
list. A random precedence search picks two random 
elements in the list and finds a proof from the earlier 
to the later element. Existence searches are cheaper 
than precedence searches. This is true because ran- 
dom existence proofs for the same list size share, 
with high probability, the last few links towards the 
end of the list, making better use of cached disk 
blocks. 

We continue by evaluating the performance char- 
acteristics of RBB-Trees. Figure [lO] contains two 
graphs, one showing how insertion time grows 
with tree size (Figure |l0|(a)) and another show- 
ing how search time grows with tree size (Fig- 
ure |l^(b)). Search experiments consisted of 1,000 
random searches for every size increment. In both 
cases, we compare trees with different snapshot 
sizes, from 100 keys to 1 million keys per snapshot. 
Searches are roughly equivalent across all snapshot 
sizes, since the "shape" of the tree is independent 
of how frequently the authentication labels are com- 
puted. However, different snapshot sizes affect the 
variance of search performance. 

Smaller snapshot sizes result in more disk blocks 
stored, because they create more versions of par- 
tially full blocks. Table [l] shows the disk size of 
a three million key RBB-Tree with varying snap- 
shot sizes. This makes shorter-snapshot trees more 
expensive during insertion, as can be seen in Fig- 
ure |l(i|(a). 

Finally, we graph proof sizes in skip lists (Fig- 



Distance (millions) 
(a) Skip list Proof Size 



Size (millions) 
(b) RBB-Tree Proof Size 



Figure 11: Proof sizes (minimum, average, maximum) 
in skip lists and RBB-Trees vs. structure size, (a) Proof 
size vs. distance between the proof ends of a skip list 
proof, (b) Proof size vs. tree size. 

ure |ll|(a)) and RBB-Trees (Figure |ll|(b)). Both 
graphs show proof sizes in KBytes, over 10,000 uni- 
form random trials in a skip list of 100 million ele- 
ments and an RBB-Tree of three million elements, 
respectively. The skip list graph uses the element 
distance as the x axis — the distance of elements i 
and j is j — i elements. The curve starts out as 
a regular square logarithmic curve, except for large 
distances, close to the size of the entire list. We con- 
jecture that the reason for this exception is that for 
random trials of distance close to the entire list size, 
all randomly chosen proofs are worst-case proofs, 
including every link of every level between source 
and destination, although we must explore this ef- 
fect further. The RBB-Tree graph shows a regular 
logarithmic curve. 

6.2 System Performance 

Although microbenchmarks can be helpful in un- 
derstanding how the basic blocks of Timeweave per- 
form, they cannot give a complete picture of how the 
system performs in action. For example, very rarely 
does a Timeweave machine need to insert thousands 
of elements into a skip list back-to-back. As a re- 
sult, the disk block caching available to batched in- 
sertions is not available for skip list usage patterns 
exhibited by Timeweave. Similarly, most searches 
through timelines only span short distances; for 
one second-long timeline time steps with one en- 
tanglement process per peer every 10 minutes, a 
Timeweave machine barely needs to traverse a dif- 
ference of 10 x 60 = 600 elements to extract a prece- 
dence proof, unlike the random trials measured in 
Figure |[ 

In this section we measure the performance of 
a Timeweave machine in action. Assuming that 
the machine uses timeline steps that last one sec- 
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Figure 12: Timeweave performance for different thread- 
per-step ratios. The errorbars show one standard devia- 
tion around the average, (a) Insertion time vs. tree size, 
(b) Search time vs. tree size. 

ond, we measure the amount of time, per second, 
that the machine spends on Timeweave mainte- 
nance. Timeweave maintenance consists of the dif- 
ferent steps taken to verify, archive and acknowledge 
timeline threads. By varying the number of thread 
messages arriving at the Timeweave machine per 
time step, we simulate the maintenance loads result- 
ing from different service set sizes. For example, if 
the entangled service set consists of 1200 Timeweave 
machines, and they all entangle with each other 
once every 600 steps (i.e., once every ten minutes), 
then every Timeweave machine sends and receives 
two threads per time step. In our experiments, we 
combine the receipt message sent by the Timeweave 
machine with the next thread message originating 
from the same machine. Although the same number 
of entanglement processes take place as in the pro- 
tocol described in Section [|, some redundant data 
transmissions are eliminated. 

Figure |l2|(a) shows the time it takes a single 
machine to perform Timeweave maintainance per 
second-long time step. The roughly linear rate at 
which maintenance processing grows with the ratio 
of threads per time step indicates that all-to-all en- 
tanglement can scale to large entangled service sets 
only by limiting the entanglement frequency. How- 
ever, for reasonably large service sets, up to 1000 
Timeweave machines for 10-minute entanglement, 
maintenance ranges between 2 and 8% of the pro- 
cessing resources of a PC-grade server. 

Figure |l2|(b) shows the amount of data sent per 
time step from a single Timeweave machine. Al- 
though the data rate itself is no cause for con- 
cern, the number of different destinations for secure 
transmissions could also limit how all-to-all entan- 
glement scales. Again, for entangled service sets 
and entanglement intervals that do not exceed two 
or three threads per time step, Timeweave mainte- 



nance should not pose a problem to a low-end server 
machine with reasonable connectivity. 

7 Conclusion 

In this work we seek to extend the traditional idea of 
time stamping into the concept of a secure timeline, 
a tamper-proof historic record of the states through 
which a system passed in its lifetime. Secure time- 
lines make it possible to reason about the tempo- 
ral ordering of system states in a provable man- 
ner. We then proceed to define timeline entangle- 
ment, a technique for creating undeniable tempo- 
ral orderings across mutually distrustful service do- 
mains. Finally, we design, describe the implementa- 
tion of, and evaluate Timeweave, a prototype imple- 
mentation of our timeline entanglement machinery, 
based on two novel authenticated data structures: 
append-only authenticated skip lists and disk-based, 
persistent authenticated search trees. Our measure- 
ments indicate that sizes of a few hundred service 
domains can be efficiently entangled at a frequency 
of once every ten minutes using Timeweave. 

Although our constructs preserve the correctness 
of temporal proofs, they are not complete, since 
some events in a dishonest service domain can be 
hidden from the timelines with which that domain 
entangles (Section |4.3| ). We plan to aleviate this 
shortcoming by employing a technique reminiscent 
of the signed-messages solution to the traditional 
Byzantine Generals problem jig] . Every time ser- 
vice A sends a thread to peer B, it also piggybacks 
all the signed threads of other services it has re- 
ceived and archived since the last time it sent a 
thread to B. In such a manner, a service will be able 
to verify that all members of the entangled service 
set have received the same, unique timeline authen- 
ticator from every other service that it has received 
and archived, thereby verifying global historic in- 
tegrity. 

We also hope to migrate away from the all- 
to-all entanglement model, by employing recently- 
developped, highly scalable overlay architectures 
such as CAN @ and Chord |||. In this way, a 
service only entangles its timeline with its imme- 
diate neighbors. Temporal proofs involving non- 
neighboring service domains use transitive secure 
temporal mapping, over the routing path in the 
overlay, perhaps choosing the route of least tem- 
poral loss. 

Finally, we are working on a large scale dis- 
tributed historic file system that enables the auto- 
matic maintenance of temporal orderings among file 
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system operations across the entire system. 
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